1. Technical Field
The invention relates to a computer bus architecture. More particularly, the invention relates to multi-master bus operation where bus masters use different sized transactions in a list-based task communications scheme.
2. Description of the Prior Art
A typical computer bus architecture, i.e. one that includes multiple bus masters which have differing bus sizes and that use a list-based task communications scheme, is shown in FIG. 1. For purposes of the discussion herein, a bus "master" shall mean a system element that is capable of asserting control of the system bus, e.g. for purposes of memory access. A multiple bus master architecture includes two or more such bus masters. The computer bus architecture 10 shown in FIG. 1 includes the following features:
Bus cycle conversion between a 32-bit bus 12 and a 16-bit bus 13 is performed by the bus bridge 16 (which, in this example, is a PCI bus bridge).
Access to a shared system RAM 15 by the bus bridge 16 is arbitrated through direct memory access (DMA) protocols and thus interleaved with accesses to the shared system RAM 15 by a microprocessor 14 (which, in this example, is an m68000 microprocessor, manufactured by Motorola Corp. of Schaumburg, Ill.). The microprocessor 14 communicates with an I/O controller 17 (which, in this example, is an Ethernet controller) directly through the bus bridge 16, as well as indirectly through shared data stored in the shared system RAM 15 (explained in greater detail below).
The 16/32 bit microprocessor 14 accesses 32-bit data by using multiple 16-bit bus cycles, which may be interrupted mid-transaction by DMA bus cycles.
Note that while not shown in this figure, other elements may also be present in the overall system. These other elements are generally inconsequential to the discussion herein, except to note that they do exist and occupy system address space.
The environment shown in FIG. 1 is further defined by the presence of a list-based I/O controller task communications scheme, as shown in FIG. 2. The list based task communications scheme 20 shown in FIG. 2 includes the following features:
Each list entry 22, 23, 24 comprises a self-contained task to be performed by the I/O controller 17. There may be additional arbitrary list entry fields as needed. For example, in Ethernet controller each list entry can correspond to a buffer into which a local area network data packet may be received.
Each list entry provides a linkage (shown as "Next" 25, 26 in FIG. 2) to the next list entry to process in order. The last list entry provides a NULL linkage 27 (i e., a link having a value of zero) to signify the end of the list. The list entry linkages are usually memory address pointers into the shared system RAM.
The microprocessor builds lists of list entries and passes them to the I/O controller by writing the address of the first list entry in the list Into a CurrentListEntry control register 28. This write operation transfers ownership of the list entries to the I/O controller and initiates list processing.
Upon completion of processing each list entry, the I/O controller updates the status 29, 30, 31 of the list entry, thus passing control back to the microprocessor. The I/O controller then reads and follows the "Next" linkage to the next list entry and begins processing the next list entry. This process continues until the I/O controller comes to the end of the list, at which point it goes idle until it is restarted by the microprocessor, as discussed above.
Based upon the environment and operation described above, there are two traditional approaches to managing the I/O controller task lists. Unfortunately, both of these approaches have fundamental problems and limitations.
One approach to managing I/O controller task lists is to use a simple model, much as described above, in which the microprocessor builds complete lists of tasks/entries, passes these lists to the I/O controller, and then waits for all tasks/entries to be processed. This approach has the drawback that the I/O controller is unable to process system input/output information as long as it is idle. Factors which contribute to this idle latency include the detection of the completion of a final task/entry by the microprocessor, and processing overhead that is associated with passing a new list of tasks/entries from the microprocessor to the I/O controller. In some cases, this latency leads to unacceptable performance degradation, such as when high-speed input/output information is combined with a relatively slow microprocessor. For example, in the environment described above, which consists of an Ethernet I/O controller, LAN packets could be dropped, thereby causing relatively slow retransmission algorithms to be invoked.
Another approach to managing I/O controller task lists is to have the microprocessor dynamically add new tasks/entries to the end of the active list while the I/O controller is processing. This approach seems appealing because it can eliminate I/O controller idle time. However, based upon typical hardware architecture operation and I/O controller list processing (all as discussed above), errors can occur when the I/O controller reads invalid Next linkages.
The steps leading to this error include:
The microprocessor reads the status in last task/entry and determines that the I/O controller has not completed processing the task/entry. The microprocessor determines that there is a need to make a list addition and commits to making the list addition.
The microprocessor begins updating the 32-bit Next field in the list entry by writing the first 16-bits during a local (i.e. Non-bridged) 16-bit bus cycle.
The I/O controller completes processing the last task/entry and performs a read of the Next field using DMA interleaved access, superseding the microprocessor on the bus. The I/O controller reads the new data written (as described above) and old data not yet updated by the microprocessor. The result is that the overall 32-bit data value read by the I/O controller is invalid because the microprocessor has only written 16-bits of the 32-bit next field in the list entry of interest.
The microprocessor then completes updating the 32-bit Next field in the list entry by writing the last 16-bits in a local 16-bit bus cycle.
Detecting and recovering from I/O controller address errors is complex and can introduce undesirable I/O controller idle time latency and software overhead. For example, an I/O controller address error may lead to a system hang, at worst, or may require a reset and re-initialization of the I/O controller at a minimum.
It would be advantageous to provide a technique that eliminates problems associated with known approaches to task/entry processing without requiring the provision of additional hardware functionality.